When managing resources that exist within an enterprise, the ability to describe such resources, including their logical structure and relationships with each other, is critical for allowing an administrator to visualize the enterprise. It is also important to use well-established and standardized mechanisms (such as those defined by the WS-Policy and WS-SecurityPolicy standards) when configuring resources behavior, especially with regard to how access to such resources will be secured. It is also helpful to allow administrators to associate arbitrary metadata (e.g., aliases, categories, or pointers to related information) with the resources they are managing.
However, every platform has its own method for describing the structure of its resources and the metadata that describe them. Further, such methods rarely provide a mechanism for an administrator to associate additional metadata with them, especially metadata required for configuring the behavior of third-party add-on products (e.g., Oracle Web Services Manager). In those situations where a platform actually provides some type of mechanism to store custom metadata, however, it is generally proprietary to the platform, thus making any solutions for managing third-party resources difficult and potentially prohibitively expensive to develop, especially if the product is to consistently manage resources in multiple, differing platforms.
Many enterprise products provide an ability to configure certain aspects of its behavior. One of the current solutions is to express all of the associated information as a simple, flat collection of name-value pairs or dictionary (e.g., where each name identifies one aspect of the product to be configured) and store the collection as either a block of plain text or simple XML document or database table.
Mobile applications are a rapidly expanding market. With the meteoric rise in the use of smart phones and tablets in recent years, businesses are seeking solutions to enable remote access to their services from these devices. Since many of these interactions will happen via the “cloud” (e.g., over the public Internet), it is critical that access to these services be secured. Minimally, this requires that mobile clients be authenticated but, in many cases, it also requires that messages be protected from interception and modification.
Current authentication mechanisms vary widely. Since these interactions are typically built on an HTTP transport model, the standard HTTP Basic authentication scheme is frequently used. Additionally, other new authentication mechanisms (e.g., OAUTH) are emerging and growing in popularity. For SOAP services, [WS-SecurityPolicy] provides more advanced authentication mechanisms, such as those based on the use of SAML tokens.
Message protection typically involves keeping the contents of a message confidential (e.g., preventing inspection by a third party) and ensuring that the integrity of a message is protected (e.g., preventing modification thereof). As with authentication, there are a wide number of algorithms that are currently employed to fulfill this. However, many of those that are performed at the message layer are computationally expensive, often prohibitively so on the constrained platform available on mobile devices. Therefore, most message protection is done at the transport layer using secure sockets (SSL).
Service-oriented client applications that access SOAP web services and RESTful resources often must ensure that the requests they send to a service adhere to certain requirements prescribed by the service. For example, the service might require that all clients provide a special token that identifies the user on whose behalf a request is being made. This is currently accomplished by building the client application using a comprehensive client library that provides a rich set of features to support various service-side requirements. This is often one that implements a standard API (e.g., WLS JAX-WS for SOAP or Jersey JAX-RS for REST). While this may work well in environments with relatively few constraints, such as within a JEE container, in tightly constrained environments (e.g., the iOS or Android mobile platforms) it is often unacceptable to require large, multi-megabyte libraries to enforce these behaviors. In the absence of any native support being provided by the platform, application developers are thus forced to implement each variation themselves.
Thus, there remains a need for a way to address these and other problems associated with the prior art.